Curse

Darkmane · Apr 20, 2005, 06:06 AM // 06:06

While passing the time waiting for the day we can all log in... I came across a pretty nice read from way back so to speak... It is interesting if nothing else.

Jeff Strain

Introduction

In most game development companies, there is a huge distance between the development staff and the customers. As developers, we are constantly striving to close that gap, to bring the development team into closer connection with customers by reducing the many layers of the process that involve the game moving from the developer’s mind to the gamer’s PC.

From the desk of an artist at a typical game company, each new art asset has to go through the usual approval process, after which it is passed to the programming staff who are responsible for placing it into the game. And it’s here that lengthy delays can develop between the time of actual generation and the time when one can ultimately see the asset in the game world, either internally within the company or externally, where it is sent out directly to the game testers or players.

The Challenge and the Early Solutions

A tool is the means by which you translate design ideas into a product. In the earliest games on which our team worked, such as Warcraft, we had virtually no tools at all. All four of the major game elements – art, sound, maps, and mission creation – had to be processed through a programmer and “hand placed” into the game. Because each element had to be built into the game engine by a small corps of programmers, and the amount of material they had to handle was overwhelming, the development process suffered constant delays.

It is typical in most companies that large numbers of design team members funnel all their work through a far smaller number of programmers in order to get the properties placed into the game. This “many working through few” situation creates a frequent and major bottleneck. The team members involved in the first wave of development such as the level designers or the artists might number in the dozens, and they are required to have all their work pass through the hands of the smaller programming staff, who might number five or six.

The fact is, the more you can decouple the programmers from the content of the game, the better the content will be. This is true because the content makers – the artist and animators and level designers – will see their work immediately in the game and then will be able constantly to improve upon it.

When Blizzard began development on Warcraft 2, the team decided to create a tool to aid in the mission creation process, which was called MapEdit. MapEdit allowed the placement of game assets, such as terrain art, units, and sound, to be handled by level designers rather than programmers. It significantly improved the process over Warcraft, in which missions were created in a very slow manual process. So part of the dependence on programmers was eliminated, but programmers were still necessary to add the game assets to the MapEdit database as well as for the mission logic.

We took the toolset a step further in StarCraft by including a trigger system that the designers could use to script mission logic, which eliminated the need for a programmer to code it by hand. This was a big improvement over MapEdit, because it put the responsibility for mission design into the proper hands: game and level designers. More importantly, it gave them the ability to iterate quickly and continually on the mission design, and problems of play and balance were spotted and fixed early in the creation process.

But we still had a bottleneck, because entering the art and sound assets into the StarEdit database required a programmer. During the time I was involved with StarCraft, we had an artist who came up with fantastic ideas for content and would bring art assets for me to make available in StarEdit so that he could place it them in the game world. But because all the assets had to be gated through the editor before they could be placed in the game world, it is no exaggeration to say that the artist often had to wait a couple of weeks before he finally saw his new art asset in the game.

After that long wait, if he found that there were tweaks or adjustments to be made, or if he decided to go back to the drawing board and come up with a completely new concept, he would have to take his place at the end of the line where he’d wait another few weeks before he could see his new or revised asset iterated in the game. And of course if the asset required further adjustments, or if other assets added later did not blend with the original art, it was back to square one yet again. This laborious process, and the length of time it took to get even the simplest of changes into a single piece of art, must have been tremendously frustrating to him. This sort of bottleneck is a major demoralizing factor where the entire staff faces the hurdle of a “hurry up and wait” in almost all layers of game production.

So while the Campaign Editor (StarEdit) was a major leap forward in tool design, I found I still had lessons to learn after I created it. The Campaign Editor allowed the team, and eventually the gamers themselves, to add individual assets and to get a look and feel for how they would work on a playable map. StarEdit may have been an evolutionary step forward for the development of StarCraft, but because the assets had to be added by a programmer into StarEdit, we had not completely eliminated the Programmer Bottleneck.

Improving on a Good Tool

A good game development tool makes its creator obsolete.

Tool development is an evolutionary process. While we used and benefited greatly from StarEdit, developers outside the company significantly improved upon the concept later. I was once hanging out with the Dev Team from Age of Empires, and we started talking about the StarCraft Campaign Editor. He told me they thought it was a great tool that allowed efficient building of game levels, and he admitted that his team used many of the concepts of StarEdit while creating the editor for Age of Empires. But they included a very significant improvement: They created a “Test Now” button.

StarCraft has a series of load (“glue”) screens – screens that allow the map user to select team settings, game type, etc. Each time our StarCraft team wanted to test something, they had to go through that whole sequence of glue screens before they actually got into the game. The Age of Empires team gave their designers the ability to iterate quickly with the simple addition of their “Test now” button. With that, a developer can build or alter a level and, by pressing the button, can be in that mission immediately. It may only take 30 seconds to go through the glue screens, but if each team member does 20 loads a day, and there is a team of 10 working on the game, that would be more than 1.6 hours a day lost to clicking through pointless glue screens! Given these hypothetical figures, the addition of the “Test now” button translates to a savings of nearly 500 work hours a year!

The Future and the ArenaNet Difference

Imagine an artist being able to create a piece of art and being able to see it in the game world and witness it undergoing game testing in a matter of minutes, not weeks. With our tools, this is not only possible, this is happening every day at ArenaNet. We don’t have a “developer’s build” and an “everyone else’s build.” What we’re working on, while we’re working on it, is what everyone is testing and playing.

And this is one of the things we are most excited about with our company’s process of game creation: The distance between the developers and the ArenaNet gamers is extremely short. Our artists are able to create an art asset, and because we’ve given them the tools that make it possible, the artist can place it directly into the world where within minutes it is compiled into the next build, and in as few as ten or fifteen minutes, is out to every one of our testers, being tested, being commented upon, and if necessary, being reworked. If there is a problem, the artist can institute and re-up a change that is dropped seamlessly into the testers’ games the very next time they play.

Giving our team the tools that allow them to perform as many independent functions as possible minimizes the Programmer Bottleneck. Our tools allow the team to place assets directly into the game world on their own, without jumping through hurdles and standing in line while somebody does the coding. We give them the tools that allow them to see their work nearly immediately, get feedback, and make changes in an extremely timely manner.

Tools as an Investment

It took us two years to build our game-development tools, and we know that they will never be truly finished. As long as we are using them, the tools will be refined and improved. We knew that this initial time was well spent, and that the investment of time would pay off in the end, because instead of waiting in a bottleneck for weeks, our team can see their assets in the newest build of the world on an hour-by-hour basis. This allows our team members to move on to the next project, or to reiterate the asset. What it all boils down to is this: Time invested early equals time saved later. Now that we’ve developed our tools, the game is coming along by leaps and bounds. From week to week, it progresses at amazing speed.

And as our game progresses, everyone is seeing the same build at the same time, and we are all commenting on that “universal build”. The benefit of everyone playing the same build is that you dramatically increase the likelihood that someone will spot an error and report it. The way most games are developed is that there is a global build that testers play, and multiple development builds that are only seen by one or two people at a time. Usually the tester build is refreshed once a week or so. By having one global build that everyone is playing, and posting builds multiple times per day, problems are more quickly spotted just due to the sheer number of people playing it. So, when, for example, a tester reports that a creature dies by falling to the left, and yet the creature’s corpse is shown lying facing the right, we’re able to step in and test that in the single world we are all viewing, and if the bug is verified and a change made, everyone will receive the update the next time they enter the game.

The ability to quickly iterate is particularly important when each asset builds on the others in a set. The look of a forest begins with a single tree, and our artist needs to be able to start on a series of designs and see via that first tree if his forest concept is sound. Using the old method, he might have spent many hundreds of hours on a series of tree and forest designs that all end up being dropped simply because that first tree wasn’t right for the world. Because he was not able to proof that first tree, because it was lost in the Programmer Bottleneck, he was unable to make an early judgment before proceeding with the faulty design concept. That simply doesn’t happen with our tools.

What do great tools make possible?

it·er·a·tion (\It`er*a"tion\, n.)
The act of saying or performing again.

It’s not just being able to see the assets in the game world on a daily, constantly-updated basis that is significant. The most powerful benefit of good game development tools is being able to iterate game assets repeatedly, quickly, and independently, and being able to iterate quickly and easily is the path to a great game. If a team member is able to generate a game asset such as a piece of art, a sound effect, or a quest, and after creation, to be able to iterate the asset again and again - to hone, refine and polish it – that ability makes a massive difference in the quality of a game. Whether iterating and reiterating a game asset makes it look more attractive, operate more smoothly, or perform a function more efficiently depends on what sort of asset it is. But in the end, iteration and reiteration is what raises the quality of the individual assets which in turn is what makes the difference between a good game and a great game. Time saved via the elimination of false starts is time that can be spent in including more content, or in perfecting the content already in the game.

Being able to iterate quickly and easily is the path to a great game.

Hard Truth about Timelines

All games have release dates. No matter how much we live by the “we’ll ship when it’s ready” credo, we also need to be able to make and keep commitments to our customers. So the more efficient the development process, the more content there will be. With game development, there are always trade-offs between making the date, including more content, or improving the quality of what has already been created. With good tools, you don’t need to make those choices or sacrifices.

A development team’s ability to change things disappears the closer they get to release. Even if a marvelous concept comes along at the eleventh hour, the team is not going to be willing to take the time to implement that change, or incorporate that asset, because with all the other layers with which the addition might need to interact, the time needed to proof it and make sure that it looks appropriate and works properly becomes daunting.

So it is essential that we are able to change things early, to see the game change daily, and be able to alter things “on the fly”. What really makes a great game is getting something up and running and playing it daily and being able to change it 20 times a day if needed.

From Release Day and Every Day After

From the day we release and every day after, the game will change. The release date is just one day, a tick mark on the calendar. We will be able to update, seamlessly and virtually at will. If someone reports a bug, we can fix it quickly. If we become aware of a balance issue, we can address it quickly. And as time passes, if there are improvements to technology, even those of a system-specific nature, we can exploit those improvements with an update. Say, for example, a new video card comes out that exceeds the capacity of the cards on the market at time of release. In order to allow those with the video card to have the eye-popping imagery their new hardware enables, we can create an update that makes this possible.

Part of the reason that our game system has integrity and stability is because everybody uses the system every single day. We “eat our own dog food” every day, and if we don’t like it, we change it.

We want to release a game that is as close to perfect as we can make it, and we believe that creating powerful development tools is a means to achieve that goal. The day we release our first title will be no different than any other day, and those who join us in the early hours of that first day will be playing exactly the same game that we have been playing at our office and in our homes for the last several weeks. Knowing that the more time you invest in your tools, the better the game will look and the better it will play, we’ve taken the time to make it possible for the development team to place assets directly into the game, and we’ve assured that everyone sees and interacts with the same single world on a daily basis. We believe that these are two major evolutionary steps in game development.

At the end of the day, besides the grand vision and the great team, you have to have top-notch tools to create a fantastic game.

Not a bad read! I liked it.

Darc.Syde · Apr 20, 2005, 06:32 AM // 06:32

quite informative. good to know how and why they created/went with their streaming technology. i honestly had no clue that the map editors were the same tools they used.

Narcism · Apr 20, 2005, 06:42 AM // 06:42

Great read, this tickled me though:

Quote:

We don’t have a “developer’s build” and an “everyone else’s build.” What we’re working on, while we’re working on it, is what everyone is testing and playing.

Apr 20, 2005, 06:49 AM // 06:49

heh, narc is being a naughty boy

Lamaros · Apr 20, 2005, 10:55 AM // 10:55

Why look to the past when GWars is out in a WEEK!?

Does this mean I should have a
<-- Beta Tester
now too?